home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10411 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: zk2nws.zko.dec.com!usenet
  2. From: Dave Butenhof <butenhof@zko.dec.com>
  3. Newsgroups: comp.programming.threads,comp.lang.c++,comp.unix.osf.osf1,comp.unix.programmer,comp.object
  4. Subject: Re: Looking for best design for using pthreads in C++ objects
  5. Date: Thu, 07 Mar 1996 07:48:11 -0500
  6. Organization: Digital Equipment Corportation
  7. Message-ID: <313EDB0B.FF6@zko.dec.com>
  8. References: <3128ff8b.666031216@news.clark.net> <312A0E5F.7B2C@ix.netcom.com> <31320705.41C6@zko.dec.com> <313DEF19.5B69@ix.netcom.com>
  9. NNTP-Posting-Host: kalkin.zko.dec.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (X11; I; OSF1 V4.0 alpha)
  14.  
  15. David Brownell wrote:
  16. > 
  17. > Webb Scales wrote:
  18. > >
  19. > > David Brownell wrote:
  20. > > > One of the really nice techniques is to have a "Locker"
  21. > > > class to grab mutexes
  22. > > > as needed, and then release it automatically on all exits.  [...]
  23. > > > That kind of class really helps get rid of the bugs you have due
  24. > > > to locks not getting released uniformly on all codepaths.
  25. > >
  26. > > Hmmm...this approach makes me nervous.  I assert that it's better
  27. > > to neglect to unlock a mutex than to unlock it when you shouldn't have.
  28. > 
  29. > Depends on how you're using the mutex; both bugs are deadly.  Did the
  30. > victim die because of the loss of blood first, or the kidney failure?
  31. > (Don't you just hate it when police beat up suspects?)
  32. > 
  33.  [...]
  34. > 
  35. > More complex invariants can be encapsulated in other classes rather
  36. > easily, and should be.  As in fact Webb noted later.  I didn't have time
  37. > to write out a complete C++/MT style guide; that point is a logical
  38. > combination of (a) encapsulation, and (b) the "Locker" technique.
  39.  
  40. But that's exactly what Webb was trying to say. The solution is, as you
  41. say, a COMBINATION of encapsulation and "the Locker technique". Locker
  42. alone will not solve most problems, and may create more. By claiming
  43. that "it" is a solution, you may mislead some folks to believe that
  44. putting Locker into a routine will solve all possible problems. That's
  45. incorrect and dangerous.
  46.  
  47. Having classes with destructors that clean up state, as TRIVIALLY
  48. DEMONSTRATED by Locker, is clearly the best way to apply C++ semantics to
  49. the problem of protecting thread state invariants against "unusual"
  50. routine exit. But the true solution in nearly all cases must go beyond
  51. the triviality of Locker to restore data invariants, not merely the state
  52. of the mutex!
  53.  
  54. > - Dave
  55.  
  56. ------------------------------------------------------------------------
  57. Dave Butenhof                              Digital Equipment Corporation
  58. butenhof@zko.dec.com                       110 Spit Brook Rd, ZKO2-3/Q18
  59. Phone: 603.881.2218, FAX: 603.881.0120     Nashua, NH 03062-2711
  60.                  "Better Living Through Concurrency"
  61. ------------------------------------------------------------------------
  62.